Initiated by thirteen main telecommunications operators in the world, NFV is an organization in which numerous device vendors, information technology (IT) vendors, and the like participate. The NFV is intended to define a requirement of network function virtualization of the operators and a related technical report, and expects to implement some network functions in a software form by means of an IT virtualization technology and using a general purpose high-performance and large-capacity server, a switch, and a storage device. For example, software and hardware separation may be implemented for various network devices, such as a server, a router, a storage device, and a switch, by using an NFV technology, and they may be deployed at a data center, a network node, a user home, or the like.
An existing NFV network architecture includes function nodes such as a network function virtualization infrastructure (NFVI), a virtualized network function (VNF), an element management (EM), a virtualized network function manager VNFM), a virtualized infrastructure manager (VIM), a network function virtualization orchestrator (NFVO), and an operations support system (OSS) or a business support system (BSS). The VNF runs on the NFVI, and one EM is corresponding to one or more VNFs.
When troubleshooting a VNF fault, the foregoing NFV network architecture usually uses a primary/secondary redundancy mode, that is, one VNF usually includes a primary VNF and a secondary VNF. When service transmission begins, the primary VNF is used, and when the primary VNF becomes faulty, a service on the primary VNF is handed over to the secondary VNF to ensure that the service runs normally.
However, except a reason of the primary VNF, a fault of the primary VNF may also be caused by another reason, for example, caused by another VNF associated with the primary VNF. Therefore, when the fault of the primary VNF is not caused by a reason of the primary VNF, even if the secondary VNF is started as a substitute, the fault cannot be fundamentally rectified. On the contrary, a precious resource is wasted, and service processing load of a management entity is increased.
To effectively identify a root fault of a VNF, the prior art provides a VNF fault correlation method. The method mainly includes: A VNF entity sends fault information to a VNFM, and the VNFM performs fault correlation processing on the VNF and another VNF within a management range of the VNFM; and if a reason of the root fault can be found, the VNFM is triggered to rectify the fault; or if a reason of the root fault cannot be found, the VNFM sends the fault information to an NFVO, and the NFVO troubleshoots the root fault at a whole network service (NS) layer, and if necessary, may further send the fault information to an OSS, and the OSS further performs fault correlation. Finally, a result of the fault correlation is returned to the VNFM, and the VNFM rectifies the fault.
In the foregoing fault correlation method, multiple function nodes may be needed to perform the fault correlation, and relatively long time is needed. If a carried service has an extremely strict requirement on a delay, performing the fault correlation may severely affect continuity of the service, the service may even be interrupted, and user experience is affected.